Virtual machine migration between servers

ABSTRACT

A virtual machine is migrated between two servers. A method, at the first server, dismounts a volume on which all the files relating to the virtual machine are stored, and which was previously mounted at the first server. The method, at the second server, mounts the volume on which all the files relating to the virtual machine are stored, so that the second server can host the virtual machine. In this way, the virtual machine can be migrated without having to copy all the files from the first server to the second server. The files relating to the virtual machine are stored on a storage-area network (SAN).

FIELD OF THE INVENTION

The present invention relates generally to virtual machine environments,in which guest operating systems run within virtual machines of one ormore computing devices, and more particularly to migrating a virtualmachine from one server to another server.

BACKGROUND OF THE INVENTION

Historically, a single computing device ran a single operating system.Each computer user, for instance, was assigned his or her own clientcomputing device, and that computing device ran an operating system inwhich the user could run application programs as desired. Similarly, aserver computing device ran a single operating system that ranapplication programs.

However, this type of computer architecture has disadvantages. First, itis costly, because each computing device needs a complete assortment ofprocessors, memory, and input/output (I/O) devices to properly functionwhether it is being utilized or not. Second, the use of this type ofarchitecture can be inefficient. At any given time, a given computingdevice may not be performing work, and rather is sitting idle, waitingfor a task to be performed during times when workloads increase.

Therefore, a technology has been developed in which more than oneoperating system is capable of running on a single computing device,sharing at least the memory and the processors of the computing device.Such technology is referred to as virtualization. With virtualization, agiven computing device has a number of virtual machines (VM's), or VMenvironments, where a guest operating system is run in each VM or VMenvironment. Therefore, guest operating systems for multiple computerusers can be run simultaneously on a single computing device, such as asingle server computing device. When workload demands are high, moreVM's can be instantiated and run. When workloads are low, VM's can besuspended.

Periodically, a virtual machine may have to be migrated from one servercomputing device, or server, to another server computing device, orserver. For instance, the server that is currently hosting the virtualmachine may need to be serviced, such that the virtual machine has to bemigrated to another server while the service or maintenance is beingperformed. As another example, a server may be currently hosting anumber of other virtual machines, such that the performance of thevirtual machines is suffering. Therefore, migrating one or more of thesevirtual machines to another server may be accomplished to increase theperformance of all the virtual machines.

Within the prior art, migration of a virtual machine from a first serverto a second server is typically accomplished by copying or moving allthe files relating to the virtual machine from the first server to thesecond server. These files may include configuration files, virtual diskfiles, and other types of files associated with the virtual machine.Copying or moving the files to the second server may thus be aprerequisite for the virtual machine to be migrated to the secondserver.

However, copying or moving all the files relating to the virtual machinecan be a slow process. Even with gigabit Ethernet network connections,for instance, copying or moving gigabytes of data over such a networkconnection can take a long time. As a result, virtual machine migrationcan be a slow process. For this and other reasons, therefore, there is aneed for the present invention.

SUMMARY OF THE INVENTION

The present invention relates generally to migrating a virtual machinebetween two servers. A method of one embodiment of the invention, at thefirst server, dismounts a volume on which all the files relating to thevirtual machine are stored, and which was previously mounted at thefirst server. The method, at the second server, mounts the volume onwhich all the files relating to the virtual machine are stored, so thatthe second server can host the virtual machine. In this way, the virtualmachine can be migrated without having to copy or move all the filesfrom the first server to the second server. The files relating to thevirtual machine are stored on a storage-area network (SAN).

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings referenced herein form a part of the specification.Features shown in the drawing are meant as illustrative of only someembodiments of the invention, and not of all embodiments of theinvention, unless otherwise explicitly indicated, and implications tothe contrary are otherwise not to be made.

FIG. 1 is a diagram of a system including a virtual machine that is tobe migrated from one server to another server, according to anembodiment of the invention.

FIG. 2 is a diagram of an example and representative storage-areanetwork (SAN), on which a logical volume storing the files relating to avirtual machine physically exists over a number of partitions of anumber of hard disk drives, according to an embodiment of the invention.

FIG. 3 is a flowchart of a method for migrating a virtual machine fromone server to another server without having to copy all the filesrelating to the virtual machine from the former server to the latterserver, according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE DRAWINGS

In the following detailed description of exemplary embodiments of theinvention, reference is made to the accompanying drawings that form apart hereof, and in which is shown by way of illustration specificexemplary embodiments in which the invention may be practiced. Theseembodiments are described in sufficient detail to enable those skilledin the art to practice the invention. Other embodiments may be utilized,and logical, mechanical, and other changes may be made without departingfrom the spirit or scope of the present invention. The followingdetailed description is, therefore, not to be taken in a limiting sense,and the scope of the present invention is defined only by the appendedclaims.

FIG. 1 shows a system 100, according to an embodiment of the invention.The system 100 includes servers 102A and 102B, collectively referred toas the servers 102, as well as a server 103. The term server is used ina broad and general sense, and corresponds to a single computing device.Each of the servers 102 and 103 thus includes hardware, such as memory,processors, and so on, which is not specifically shown in FIG. 1. Theservers 102 and 103 may in one embodiment be connected to one anothervia a network 104, such as an Ethernet network. The servers 102 are alsoall communicatively connected to a storage-area network (SAN) 106. TheSAN 106 may be considered a network of storage hard disk drives. Inlarge enterprises, the SAN 106 connects the multiple servers 102 to acentralized pool of disk storage. Compared to managing hundreds ofservers, each with their own disks, SAN's improve system administration.

Each of the servers 102 may host one or more virtual machine (VM's).However, just one virtual machine (VM) 108, currently being hosted bythe server 102A, is depicted in FIG. 1 for illustrative clarity andconvenience. Each of the VM's is a virtualized environment that enablesa corresponding guest operating system (OS) to run on it as if the OS inquestion were the only OS running on the server in question. In thisway, a number of operating systems can run on each of the servers 102,within a number of VM's. That is, the VM's are VM environments in thateach of the VM's appears to software running within the VM's as atraditional hardware environment.

It is noted, therefore, that the servers 102 are considered hypervisors,which are systems capable of hosting VM's. At least some embodiments ofthe invention are applicable to what are known in the art as Type IIhypervisors, which, among other things, are hypervisors that run on topof operating systems. For instance, at least some embodiments of theinvention are applicable to the hypervisors running on Microsoft®Windows® Server 2003 OS, available from Microsoft Corp., of Redmond,Wash.

The VM manager 118 running on the server 103 manages the VM's running onthe servers 102. That is, the VM manager 118 allows for administrationof the individual VM's, such as their startup, shutdown and maintenance.When a new VM is desired to be run on any of the servers 102, it isstarted from within the VM manager 118, and when an existing VM isdesired to be shutdown, it is shutdown from within the VM manager 118.The VM manager 118 performs this functionality in relation to theservers 102A and 102B through agents 112A and 112B, collectivelyreferred to as the agents 112, running on these servers. That is, theagents 112 are small software programs running on the servers 102A and102B for the purposes of performing VM-related functionality on theseservers.

The VM 108 thus includes an OS 110 running thereon, as well as a numberof application programs 114 running on the OS 110 of the VM 108. Theseapplication computer programs 114 may be word-processing programs,spreadsheet programs, presentation programs, e-mail programs,web-browsing programs, as well as other types of application computerprograms. The set of application computer programs and the OS of a givenVM are referred to as a session.

As in physical machine environments, the virtual machine environmentthat is the VM 108 has a set of files related thereto. These filesinclude configuration files, virtual disk files, and other types offiles associated with the VM 108 that are needed for the VM 108 toproperly run. In the embodiment of FIG. 1, such files are stored on alogical volume 116 of the SAN 106. The volume 116 may span, or extend,more than one partition of more than one physical hard disk drive of theSAN 106, as is described in more detail later in the detaileddescription.

A volume may be generally considered as the highest level oforganization within a file system. A volume is an area on or extendingover one or more storage devices that is managed by the file system as adiscrete logical storage unit. Each storage device, such as each harddisk drive, may contain one or more partitions. Furthermore, a volumecan exist on, or extend over, one or more partitions on the same ordifferent hard disk drives. A volume that exists on one partition isconsidered a simple volume, and a volume that exists over more than onepartition is considered a multi-partition volume.

As has been noted, the server 102A is hosting the VM 108. However, forany of a variety of different reasons, the VM 108 is to be migrated fromthe server 102A to the server 102B, as indicated by the arrow 116. Aftermigration, the VM 108 is hosted by the server 102B, and not by theserver 102A. Embodiments of the invention are thus concerned withmigration of the VM 108 from the server 102A to the server 102B in aperformance-enhanced manner.

Within the prior art, part of the migration process of the VM 108 fromthe server 102A to the server 102B involves copying or moving the filesrelating to the VM 108 from the server 102A to the server 102B. That is,the files would be individually read from the volume 116 of the SAN 106by the server 102A, and copied over the network 104 to the server 102B.The server 102B may in turn store the files on a different volume of theSAN 106, as can be appreciated by those of ordinary skill within theart. However, this copying or moving process can be slow.

Therefore, embodiments of the invention, as part of the migrationprocess of the VM 108 from the server 102A to the server 102B, do notcopy or move the files relating to the VM 108 from the server 102A tothe server 102B. Rather, in lieu of such file copying or moving, thefollowing is performed. The volume 116 is dismounted at the server 102A,where it was previously mounted at the server 102A. Thereafter, thevolume 116 is mounted at the server 102B. In this way, the filesrelating to the VM 108 can be accessed at the server 102B, withouthaving to be physically copied over the network 104 from the server 102Ato the server 102B.

It is noted that dismounting of the volume 116 at the server 102A, priorto mounting the volume 116 at the server 102B, is performed at least inpart to avoid any corruption of data stored on the server 102A. Forinstance, as will be described, as part of the dismounting process, theserver 102A flushes its file buffers of any data that is beingtemporarily stored within those buffers, so that the volume 116A asstored on the SAN 106 represents the latest version of the data of thevolume 116A as may have been modified at the server 102A. Therefore,when the server 102B mounts the volume 116, it is guaranteed to bereceiving the latest version of the data of the volume 116, and it isfurther guaranteed that the server 102A no longer has access to thevolume 116, such that the server 102A cannot change the data afterhaving dismounted the volume 116.

Mounting of a volume is the process of causing a remote volume, such asthe volume 116 on the SAN 106, to be available for access locally by aserver. The SAN 106, and thus the volume 116, are visible to both theservers 102A and 102B. However, only the server that has currentlymounted the volume 116 is able to access the volume 116, such as read,write, modify, and delete the files stored on the volume 116. In oneembodiment, just one server has the volume 116 mounted thereat at anygiven time. Furthermore, it is presumed herein that the user has set upthe system 100 so that the volume 116 is just mounted at the server 102Aat the beginning, prior to the migration process.

Thus, rather than copying or moving the files related to the VM 108 fromthe server 102A and 102B as part of the migration process of the VM 108,as in the prior art, embodiments of the invention dismount the volume116 on which the files are stored, at the server 102A, and then mountthe volume 116 at the server 102B. The net effect is the same, insofaras the server 102B is able to access the files regardless of whetherthey are copied or moved from the server 102A thereto or whether thevolume 116 is dismounted at the server 102A and then mounted at theserver 102B. In this way, this part of the VM migration process isperformed significantly more quickly than in the prior art.

The entire migration process as performed in one embodiment of theinvention is described in detail later in the detailed description inrelation to FIG. 3. However, it is noted that for the volume 116 to bemounted at the server 102B after having been dismounted at the server102A, the server 102B has to be able to identify the volume 116 withinthe SAN 106. That is, the server 102B has to know the identity of eachpartition on each hard disk drive on which the volume 116 exists.

In some situations, this is not a simple matter of the server 102Aindicating the identity of the volume 116 to the server 102B, becausedifferent servers may identify volumes differently, even where theservers are running the same file system. Therefore, in one embodiment,a process is performed to delineate the partitions and the hard diskdrives on which the volume 116 exists, so that the server 102B is ableto properly mount the volume 116 using this information. In particular,the server 102A performs this identification process, and its agent112A, via the VM manager 118, notifies the agent 112B on the server 102Bof the identity of the volume 116 so that the volume 116 can be properlymounted at the server 102B after having been dismounted at the server102A.

FIG. 2 shows a representative example of the SAN 106, according to anembodiment of the invention. The SAN 106 includes two physical hard diskdrives 202A and 202B, collectively referred to as the hard disk drives202. The hard disk drive 202A is divided into two partitions 204A and204B, collectively referred to as the partitions 204. The hard diskdrive 202B has been divided into three partitions 206A, 206B, and 206C,collectively referred to as the partitions 206.

The volume 116 includes, or extends over, or exists on the partition204B of the hard disk drive 202A, and the partition 206B of the harddisk drive 202B. Therefore, these partitions 204B and 206B, as well astheir hard disk drives 202A and 202B, respectively, have to beidentified in a server-neutral and substantially universal way, so thatthe server 102B is able to have the volume 116 mounted thereat. That is,the server 102A has to provide a server-neutral and substantiallyuniversal identification of the partitions 204B and 206B on the harddisk drives 202A and 202B, respectively, and provide this identificationto the server 102B, for the server 102B to be able to mount the volume116 after the server 102A has dismounted the volume 116.

In one embodiment, as is described in more detail later in the detaileddescription in relation to FIG. 3, the server 102A obtains the followinginformation for each partition, or extension, of the volume 116. First,a signature of the hard disk drive on which each partition, orextension, of the volume 116 is obtained. The signature of a hard diskdrive uniquely identifies that drive in a server-neutral andsubstantially universal way, such that the signature of the drive is thesame to both the server 102A and the server 102B. Next, the startingoffset on the hard disk drive in question for each partition isobtained. The starting offset specifies where a given partition startson the hard disk drive. Finally, the size of the extension, or thepartition, for each partition is obtained.

Thus, by determining the unique signature of a hard disk drive for eachpartition, and where each partition, or extension, starts on the harddisk drive, and the size of each partition, or extension, aserver-neutral and substantially universal identification of the volume116 is obtained. This identification includes a list of the unique harddisk drive signature, the starting offset, and the size, of eachpartition, or extension, on which the volume 116 exists. Using thisinformation, the server 102B is able to properly mount the volume 116after it has been dismounted at the server 102A.

FIG. 3 shows a method 300 for migrating the VM 108 from the server 102Ato the server 102B, according to a particular embodiment of theinvention. Communication between the server 102A and the server 102B isaccomplished within the method 300 via the VM manager 118 running on theserver 103. As depicted in FIG. 3, some parts of the method 300 arespecifically performed by the server 102A, such as by the agent 112Arunning thereon, whereas other parts are specifically performed by theserver 102B, such as by the agent 112B running thereon. Furthermore,although a particular ordering of the performance of the parts of themethod 300 is shown in FIG. 3, in other embodiments, the method 300 maybe performed at least in a partially different order, as can beappreciated by those of ordinary skill within the art.

The server 102A first delineates the identification of the volume 116that stores all the files related to the VM 108. This identification, ashas been described, is a server-neutral and substantially universalidentification of the volume 116, in that this identification canappropriately identify the volume 116 to both the server 102A and theserver 102B. In one embodiment, the server 102A first determines thenumber of partitions, or extensions, over which the volume 116 extends.For each partition or extension, the server 102A determines the startingoffset, the extension size, and the disk signature. The set of all thestarting offsets, extension sizes, and disk signatures for all thepartitions or extensions of the volume 116 make up the identification ofthe volume 116.

For example, in relation to the Microsoft® Windows® Server 2003operating system, available from Microsoft Corp., of Redmond, Wash., theapplication programming interface (API) DeviceIoControl exposed by theOS may be called for each extension of partition of the volume 116, viathe control code IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS. In return, the OSprovides the disk number, starting offset, and the extension size of thepartition in question. However, the disk number, specifying a hard diskdrive of the SAN 106, is not universal, and rather is particular just tothe server 102A. Therefore, the API DeviceIoControl is again called,with the control code IOCTL_DISK_GET_DRIVE_LAYOUT_EX, to obtain a disksignature for the particular disk number. The disk signature, bycomparison, is universal and server neutral.

The VM 108 is then turned or powered off (308). Turning off or poweringoff in this sense is itself a virtual operation, since the server 102Ais not physically turned off, but rather the VM 108 is virtually turnedoff, as can be appreciated by those of ordinary skill within the art. Inone embodiment, such turning or powering off is accomplished by callingan appropriate API exposed by the given virtualization environmentsoftware being employed.

Thereafter, the VM 108 is unregistered, or deregistered, at the server102A (310). Unregistration, or deregistration, of the VM 108 at theserver 102A means that the server 102A is no longer hosting the VM 108.Because only one server can host a given VM at any given time, the VM108 is now partially ready to be hosted at the server 102B.Deregistration, or unregistration, can in one embodiment also beaccomplished by calling an appropriate API exposed by the givenvirtualization environment software being employed.

Next, any file buffers at the server 102A that may be temporarilybuffering data of the files relating to the VM 108 on the volume 116 areflushed (312). Buffer flushing ensures that the most recent and correctversion of all the files relating to the VM 108 are properly reflectedon the physical hard disk drives on which the volume 116 exists, and notonly in the file buffers themselves, as can be appreciated by those ofordinary skill within the art. Buffer flushing may in relation to theMicrosoft® Windows® Server 2003 OS be accomplished by calling theFlushFileBuffers API.

The volume 116 is then dismounted from the server 102A (314), so that itcan be mounted at the server 102B for hosting of the VM 108 at theserver 102B. Dismounting the volume 116 means that the volume 116 is nolonger accessible by the server 102A, even though the SAN 106 on whichthe volume 116 exists remains visible to the server 102A. In oneembodiment, in relation to the Microsoft® Windows® Server 2003 OS, theDeviceIoControl API is controlled with the control codeFSCTL_DISMOUNT_VOLUME to dismount the volume 116, and thereafter the APIDeleteVolumeMountPoint is called to completely remove the volume 116from being accessible at the server 102A.

Finally, the server 102A transmits the identification of the volume 116,previously determined in part 302 of the method 300, to the server 102B,via or through the VM manager 118 running on the server 103 (316). Forinstance, the agent 112A running on the server 102A may communicate theidentification of the volume 116 to the VM manager 118 running on theserver 103, which it turn communicates the identification of the volume116 to the agent 112B running on the server 102B. Thus, the server 102Breceives the identification of the volume 116 from the server 102A viathe VM manager 118 running on the server 103 (318).

The server 102B then mounts the volume 116 using the identification ofthe volume 116 that has been provided by the server 102 (320). Mountingthe volume 116 may include first ensuring that the volume 116 can beproperly found on the SAN 106. For instance, the server 102B may, inrelation to the Microsoft® Windows® Server 2003 OS, call the APIFindFirstVolume to find the first volume on the SAN 106, and then stepthrough all the volumes on the SAN 106 by calling the API FindNextVolumein an iterative manner. For each volume found, the disk signatures,starting offsets, and extension sizes of the partitions, of the volumeare compared to the identification of the volume 116 provided by theserver 102A. Once the identical volume has been found, the server 102Bthen mounts the volume 116, such as by using the API SetVolumeMountPointas exposed by the Microsoft® Windows® Server 2003 OS.

Thereafter, the server 102B registers the VM 108 (322). Registration ofthe VM 108 means that the server 102B is now hosting the VM 108. Thus,the VM 108 has been migrated from the server 102A to the server 102B,without having to copy all the files relating to the VM 108 from theserver 102A to the server 102B. The VM 108 is now accessible, and cannow be turned on as needed (324), by calling an appropriate API of thegiven virtualization environment software being employed.

It is noted that, although specific embodiments have been illustratedand described herein, it will be appreciated by those of ordinary skillin the art that any arrangement calculated to achieve the same purposemay be substituted for the specific embodiments shown. This applicationis thus intended to cover any adaptations or variations of embodimentsof the present invention. Therefore, it is manifestly intended that thisinvention be limited only by the claims and equivalents thereof.

1. A method for migrating a virtual machine from a first server to asecond server, comprising: at the first server, turning off the virtualmachine; after turning off the virtual machine, dismounting a volume onwhich all files relating to the virtual machine are stored and which waspreviously mounted at the first server, such that upon dismounting, thevolume is no longer accessible at the first server; and, prior todismounting the volume, delineating a server-neutral identification ofthe volume; transmitting the server-neutral identification of the volumeto the second server; at the second server, after the volume has beendismounted at the first server, mounting the volume on which all thefiles relating to the virtual machine are stored; after mounting thevolume, turning on the virtual machine, such that the virtual machine ismigrated from the first server to the second server without copying allthe files relating to the virtual machine from the first server to thesecond server.
 2. The method of claim 1, further comprising, at thefirst server, prior to dismounting the volume, unregistering the virtualmachine at the first server.
 3. The method of claim 1, furthercomprising, at the first server, prior to dismounting the volume,flushing any file buffers of the first server that have buffered any ofthe files relating to the virtual machine.
 4. The method of claim 1,further comprising, at the second server, after mounting the volume,registering the virtual machine at the second server.
 5. The method ofclaim 1, where the server-neutral identification of the volume is aserver-neutral and substantially universal identification of the volume.6. The method of claim 5, further comprising, at the second server,prior to mounting the volume, receiving the server-neutral andsubstantially universal identification of the volume from the firstserver, wherein the identification of the volume is used by the secondserver to mount the volume thereat.
 7. The method of claim 5, whereindelineating the server-neutral and substantially universalidentification of the volume comprises: determining a number ofpartitions over which the volume extends; and, for each partition overwhich the volume extends, determining a starting offset, extension size,and disk signature of the partition, wherein the identification of thevolume includes the starting offset, extension size, and disk signaturefor each partition over which the volume extends.
 8. The method of claim1, wherein the files relating to the virtual machine are physicallylocated on a storage-area network (SAN), are visible to both the firstserver and the second server, but initially accessible just to the firstserver.
 9. A system comprising: a storage-area network (SAN) physicallystoring all files relating to a virtual machine over one or morepartitions of hard disks of the SAN; a first server at which a volumelogically storing all the files relating to the virtual machine ismounted and at which the virtual machine is hosted; a second server towhich the virtual machine is to be migrated; a first agent running onthe first server to dismount the volume; and, a second agent running onthe second server to mount the volume at the second server, wherein thevirtual machine is migrated from the first server to the second serverwithout copying all the files relating to the virtual machine from thefirst server to the second server, by: the virtual machine being turnedoff at the first server, and after the virtual machine being turned offat the first server, a volume on the SAN and on which all the filesrelating to the virtual machine are stored being dismounted at the firstserver, such that upon dismounting, the volume is no longer accessibleat the first server, and after the volume has been dismounted at thefirst server, the volume being mounted at the second server, and afterthe volume has been mounted at the second server, the virtual machineturned on at the second server, wherein the first agent is further todelineate a server-neutral identification of the volume prior todismounting the volume, and to transmit the identification of the volumeto the second agent.
 10. The system of claim 9, wherein the first agentis further to turn off the virtual machine and unregister the virtualmachine from the first server prior to dismounting the volume.
 11. Thesystem of claim 9, wherein the second agent is further to register thevirtual machine at the second server, such that the virtual machine ishosted at the second server, and to turn on the virtual machine, aftermounting the volume.
 12. The system of claim 9, further comprising athird server hosting a virtual machine manager, wherein the first agentis to transmit the identification of the volume to the second agent viathe virtual machine manager, and wherein the second agent is to receivethe identification of the volume from the first agent via the virtualmachine manager, and is to use the identification of the volume to mountthe volume thereat.
 13. The system of claim 12, wherein theidentification of the volume comprises, for each partition over whichthe volume extends, a starting offset, extension size, and disksignature of the partition.
 14. An article of manufacture comprising: anon-transitory and tangible computer-readable medium; and, means in themedium for migrating a virtual machine from a first server to a secondserver without having to copy all files relating to the virtual machinefrom the first server to the second server, wherein a part of the meansat the first server turns off the virtual machine at the first server,and after turning off the virtual machine at the first server dismountsat the first server a volume on which all the files relating to thevirtual machine are stored, such that upon dismounting, the volume is nolonger accessible at the first server, wherein a part of the means atthe second server of the means mounts at the second server the volume onwhich all the files relating to the virtual machine are stored after thevolume has been dismounted at the second server, and after mounting thevolume at the second server turns on the virtual machine at the secondserver, and wherein the part of the means at the first server is todelineate a server-neutral identification of the volume prior todismounting the volume, and to transmit the identification of the volumeto the part of the means at the second server.
 15. The article ofmanufacture of claim 14, wherein the part of the means at the firstserver unregisters the virtual machine from the first server prior todismounting the volume.
 16. The article of manufacture of claim 14,wherein the part of the means at the second server registers the virtualmachine at the second server after mounting the volume.
 17. The articleof manufacture of claim 14, wherein the server-neutral identification ofthe volume is a server-neutral and substantially universalidentification of the volume.
 18. The article of manufacture of claim17, wherein the part of the means at the second server is to receive theidentification of the volume, and to use the identification of thevolume to mount the volume thereat.
 19. The article of manufacture ofclaim 17, wherein the identification of the volume comprises, for eachof one or more partitions over which the volume extends, startingoffset, extension size, and disk signature of the partition.
 20. Thearticle of manufacture of claim 14, wherein the files relating to thevirtual machine are physically located on a storage-area network (SAN),are visible to both the first server and the second server, butinitially accessible just to the first server.